История продукта KOMRAD Enterprise SIEM
Попробуем разобраться с хронологией создания KOMRAD Enterprise SIEM. Не так давно мы выложили историю, здесь приводить не будем, поскольку это объемная таблица.
Визуализация нацелена показать общий вектор развития продукта. Но сразу возникает вопрос, почему представлена только версия 4? Ответ прост, версия 4, является полным перезапуском продукта. Почему его пришлось перезапускать? Комрад 3 с самого начала опирался на форк опенсорса и его доработка являлась, адаптацией для Российского рынка + он имел сертификат, но когда начались серьёзные проекты, разработка зашла в тупик и не могла менять архитектуру решения, не могла довести новые функции до стабильности.
В 2020 было принято решение перезапустить проект, написать код с нуля, заложить архитектуру, набрать команду людей с горящими сердцами и определить набор функций для выпуска минимальной версии с которой начнётся развитие нового, по сути, продукта. Это было не просто смело, а очень смело, поскольку на тот момент конкурентов в сегменте рынка практически не было. Сейчас ситуация сильно поменялась, все ИБ-компании строят свои экосистемы, в центре которых находятся собственные SIEM.
На этапе построения архитектуры было много вариантов, в тот момент времени законодателем мод был Elastic, он регулярно попадал в Квадрант Gartner. В первую очередь необходимо было выбрать базу данных. Мы отказались от ElasticSearch, потому что он забирает на себя много ресурсов, а мы хотели сделать систему, которую можно запустить даже на слабом ноутбуке. В качестве базы для внутренних нужд сервисов было принято решение использовать Postgresql, это популярный и качественный инструмент, но при больших нагрузках он тоже начинает отнимать большое количество ресурсов, для того, чтобы этого не происходило, мы использовали Timescaledb, главным образом решающего задачу времени вставки, в качестве эксперимента мы добавляли поддержку CockroachDB, но в последующем отказались, ввиду того, что никто ей не пользовался, а поддержка отнимала. И тут уже на горизонте стал появляться ClickHouse, мы долго сомневались, поскольку изначально он был сырой, но процесс сертификации расставил всё на свои места, мы не могли гарантировать безопасную сборку Timescaledb, а это обязательное требование и мы всё же решились перейти на ClickHouse.
Наравне с базой нам нужна была мощная шина данных, способная справиться с потоком данных с коллекторов и гарантировать безопасность общения сервисов. RabbitMQ или Kafka были написаны на сторонних для нашего проекта языках, и накладывали бы на нас обязательства по их поддержке, как заимствованных компонентов, поэтому решено было использовать NATS, который был модифицирован для наших целей. Для управления активами был заимствован nmap из состава компонентов Сканер-ВС
Остальные компоненты системы создавались уже с нуля. В первую очередь коллекторы и управляющий сервер, затем модуль фильтрации, за который отвечает сервис komrad-processor, одним из самых важных и сложных компонентов является диспетчер корреляции. Если сильно упростить исходную логику, то события фильтровались, а после на отфильтрованные события накладывался фильтр корреляции. Модель корреляции тестировалась месяцами и в процессе для удобства решили сделать конструктор правил корреляции. Впоследствии стало понятно, что кодом при наличие конструктора уже мало кто будет пользоваться. Нам удалось добиться гарантии срабатывания правил корреляции. После корреляции мы добавили модуль управления инцидентами и реакциями. Добавили уведомления в Госсопка, syslog и smtp, этого было достаточно для минимальной версии продукта. Она вышла и получила сертификат.
После была версия 4.3.58 - это большая работа над ошибками, в ней мало новых функций, но много исправлений. Про новое в версии 4.3.58 можно почитать здесь.
Сейчас идёт разработка версии 4.5.Х, а что в ней нового мы писали в другом посте.